The GeoServer paltform supports a number of different open web service specifications, Web Feature Service, Web Map Service, and Web Coverage Service. This article explains the design of the GeoServer service model, intended to illustrate the bigger picture to someone interested in developing new types of open web services with GeoServer.

Plain Old Java Objects

Central to the GeoServer service model is the notion of Plain Old Java Objects ( POJO's ). Put simply, a service is composed of a collection of POJO's which implement the operation logic of the service. So why use plain old java objects?

Simplicity

Pojo's are straight forward, someone developing a new service does not have to become familiar with a new set of api.

Portability

Since by definition a pojo does not implement a particular interface, they are not tied to any particular plugin system or framework. This makes the job of adapting the service to a particular platform easier.

Seperation of Concerns

A service should be concerned with the logic and semantics of the service, that is all. Implementing an interface often leads to other concerns being addressed.

And the list goes on. So as an example lets consider the following class implementing a Web Map Service.

class WebMapService {
   
  Document getCapabilities();

  Image getMap();

  ....
}

Each operation of the service simply maps to a method of the class.

Request Dispatching

A service by definition handles requests from clients. A single request specifies the following information:

1. Identification of the service
2. Operation to be performed
3. Any paramters to the operation

A request can come in a variety of forms : HTTP GET/POST, SOAP, RPC, etc... However none of this matters to the service. The service worries about implementing the logic of its operations, and nothing else. It is up to the platform to worry about what protocol is being used.

Moving back to the Web Map Service, example, lets consider the GetMap operation. Along with many others, the operation takes the layers and bbox parameters. So the implementation looks like:

class WebMapService {

   void setLayers( List layers );

   void setBbox( BoundingBox bbox );

   Image getMap();

}

Each parameter of the operation maps directly to a property of the class, and a setter method. Consider the following http GET request for the GetMap operation:

http://geo.openplans.org/geoserver/wms?request=GetMap&layers=states&bbox=-180,-90,180,90

This request get mapped or dispatched to the WebMapService as depicted below.

Schema Support with EMF

All open web services defined by the OGC are accompianied by an xml schema which defines the protocol of the service. For instance, the following xml schema framgment defines the syntax of a wfs.

<xsd:complexType name="GetCapabilitiesType">
     
      <xsd:attribute name="version" type="xsd:string"/>
      <xsd:attribute name="service" type="xsd:string"/>

</xsd:complexType>

The Eclipse Modelling Framework is a code generation and modelling tool which can create a java object model from an xml schema. So using EMF we can create the following class:

getMapMapping.png (image/png)